A software-defined network (SDN for short) intends to transform a conventional closed network into an open environment, and can also implement programming, as a computer does. The OpenFlow technology is a manner of implementing an SDN. The OpenFlow technology is proposed by Stanford University at the earliest, which aims to solve various bottlenecks generated when a current network is confronted with a new service with an innovative network interconnection idea based on an existing Transmission Control Protocol (TCP for short)/Internet Protocol (IP for short) technical condition. OpenFlow converts a packet forwarding processing process implemented originally and completely by a single network element into a process completed jointly by an OpenFlow forwarder and a controller, thereby implementing separation of data forwarding from service control. The controller controls a flow table in the OpenFlow forwarder by using a standard interface, that is, the OpenFlow protocol, thereby implementing centralized control over an entire network.
One of the most important components in the OpenFlow forwarder is a flow table, the flow table is formed by a large quantity of flow table entries, and each flow table entry is a packet processing rule. After receiving a packet, the forwarder may obtain an action needing to be executed by querying a flow table entry. The forwarder may include multiple flow tables, and the controller delivers a flow table entry specific to a service flow for one or more flow tables of the forwarder.
Each OpenFlow flow table entry is formed by flow information (such as, flow match field), a counter and an action (Action). For details, reference is made to what is shown in Table 1 as follows:
TABLE 1Flow matchCounterActionfield
The flow match field in Table 1 is match information formed by multiple fields, is an identifier of a flow table entry, and may be used for defining a flow. Table 2 shows an example of a flow match field, and the flow match field is formed by ten fields.
TABLE 2ExchangeVLANMACMACEthernetIPIPIPTCPTCPportidentifiersourcedestinationtypesourcedestinationportsourcedestinationaddressaddressaddressaddressaddressaddress
The counter in Table 1 is used for counting traffic related data, and the counter may perform individual setting according to each flow table, each flow or each port.
The action in Table 1 indicates a type of an action that should be executed on a packet matching the flow table entry, for example, an action type such as forwarding or dropping. Action types defined in the current Openflow protocol include:
Output: forwarding a packet from a specific port;
Set-Queue: forwarding a packet by using a specific forwarding queue;
Drop: dropping a packet;
Group: grouping multiple flows into an action to perform processing;
Push-Tag/Pop-Tag: performing encapsulation or de-encapsulation;
Set-Field: changing a packet header; and
Change-TTL: changing a TTL field.
Action modes of a current flow table include two types: an active mode and a passive mode. In the active mode, a controller delivers flow table information collected by the controller to a forwarder actively, and subsequently the forwarder may directly perform forwarding according to a flow table; the passive mode refers to that when having not found any matching flow table entry record after receiving a packet, a forwarder forwards the packet to a controller, and the controller decides how to perform processing, and delivers a corresponding flow table entry to the forwarder.
In a flow table of the conventional technology, a flow and an action are directly associated, and when actions corresponding to some flows are the same, a corresponding action needs to be saved in a flow table entry for each flow, and therefore a large quantity of redundancy occurs in information stored in a forwarder, and maintenance is also very difficult. For example, when an action is changed, related flow table entries need to be all changed.